Forms embedded inside Kexi

Introduction

Kexi uses KFormDesigner's (KFD) libraries to implement form editing and presentation features. Since KFD application itself is considered to be more advanced, like Qt Designer, (especially in terms of exposing most Qt API), Kexi uses simplified version of KFD (without code duplication, though), by hidding certain more advanced options, like advanced widget, advanced properties. Kexi also adds more intuitive options not found in Qt Designer or KFD, like a separate widget for pixmaps and another for text label, while other apps have these two merged within one widget.

Table of Contents       Introduction    1. Anatomy of the Form Window      1.1. Inheritance diagrams    2. Kexi form types      2.1. Standard Form      2.2. Continuous Form      2.3. Autoform      2.4. Datasheet view      2.5. Subform Widget      2.5.1. Special features      2.6. Form helper within Table View      2.7. Quick Forms    3. Problems      3.1. Issues with IDEAl and Tabbed-Pages modes      3.2. Form Resize Modes for form windows inside Kexi      3.3. Related form's properties      3.4. Notes      3.5. "Edit indicator" for standard forms

1. Anatomy of the Form Window

 2005-02-23, jstaniek

Graph of objects inclusion within a form window:

1.1. Inheritance diagrams

 KexiFormScrollView -> [ KexiScrollView,
                          KexiRecordNavigatorHandler,
                          KexiSharedActionClient,
                          KexiDataAwareObjectInterface,
                          KexiFormDataProvider ]

 KexiFormDataProvider -> KexiDataProvider

 KexiFormView -> KexiDataAwareView -> KexiViewBase

 KexiDBForm -> [ QWidget,
                  KFormDesigner::FormWidget,
                  KexiDataItemInterface ]

 KexiDBLineEdit -> [ KLineEdit,
                     KexiDataItemInterface ]

 KexiSubForm -> [ QScrollView ]

2. Kexi form types

 jstaniek, mar 2005

2.1. Standard Form

A form which is designable using KFD component. It's content takes a full size of the window. On design time user can easy resize contents size thanks to existence of the special outer area. In case when a form.

On preview time (Data Mode), outer area dissapears, additional space bacames empty.

If data-aware, a single form usually displays a single data record (row). In more complex case a form can be not data-aware but instead can just act as a container for a number of user-visible texts and buttons, and one or more data-aware subforms - see 2.5.

[TODO: a shot with annotation]

Status: IMPLEMENTED in Kexi 0.8

2.2. Continuous Form

Continuous form consists of a number of horizontal areas. Each area is in fact a separate form displaying a single database record. Having a continuous form without binding it to a data source is not reasonable.

On design time, user edit's contents of a single form's area; this is nothing different from editing a standard form. As mentioned above, after switching to Data Mode, the designed form will be multiplied to fill entire container's area.

Continuous forms can be used as toplevel forms or can be nested inside a standard form.

Status: PLANNED after Kexi 1.0

2.3. Autoform

Autoform, or automatic form is a form type generated by Kexi each time it is opeoned by user. An action will be added to enable the user to edit the form. The reverse operation (edited --> autoform) may also be possible, but all user changes will be lost. A number of predefined properties are available to change visual and behavioural aspects of such a form, e.g.:

• data source - a query or table
• form layout: there will be two (more?) layouts available: 'columnar' mode, with widgets displayed in columns (the most basic layout, with the possibilty of filling the grid by lines or columns first) and a justified mode (same as in MSA).

Note1: 'Autoform' term here is not the same as in MSA. In MSA, autoform is just an ordinary form created using wizard/creator (after asking user just for picking a data source). After creation, the resulting form is no longer automatically updatable (with small exception for warnings about invalid data sources, coming with MSA 2003+).

Note2: All issues for note 1 are valid for reports too.

A new flow layout will be created (basically a grid which numbers of lines and columns change dynamically depending on its geometry), inspired by the one available in qt3 examples. This layout will also be available as a new item in Layout menu. To store it and for compatibility reasons, it will be saved as grid, with additional "customLayout" property.

Status: PLANNED after Kexi 1.0

See also Autoforms: Development Talks

2.4. Datasheet view

This is the same solution as data view for tables or queries: user can see a table filled with records of data. KexiDataTableView class is reused for that.

Datasheet view is just other method of displaying a form's data - the data source definition (a query) is the same as form's data. This view should be accessible without additional design efforts at user's side - just by a toolbar button or so.

Status: PLANNED after Kexi 1.0

2.5. Subform Widget

In fact, subform is not a special type of a form, it's a container widget able to display another form within it's parent form and thus it's able to nest a form within another form. It's possible to do a dipper level of nesting, even while usability of such a thing is not necessary clear.

Status: MOSTLY IMPLEMENTED since Kexi 0.8; HIDDEN until 1.0

2.5.1. Special features

(unimplemented)

• "hideIfEmpty" property hides a subform if it doesn't contain any records. After hidding, the form should take the same amount of space.

2.6. Form helper within Table View

Sometimes, a user may find it more convenient to navigate through data rows using TableView and at the same time, having a form for current row's data (record) visible in parallel. The solution requires just to insert a "form section" below the tabular view.

(the screenshot is taken from OO.org base 2.0 Beta)

This additional form section will be most probably an autoform, so user won't care about defining it.

Note1: DataKiosk application already has Data Table/Editor Form functionality, separated using tabs.

Note2: MSA 2007 adopted the idea and named it as split forms. See here, here and here.

Status: PLANNED after Kexi 1.0

2.7. Quick Forms

The proposal is that original MSA's 'autoform' entity (i.e. a form which is created by single button click, after just picking a data source) could be named somewhat like 'Quick Forms'. Most probably, AutoForms can be used for generating a form quickly.

3. Problems

3.1. Issues with IDEAl and Tabbed-Pages modes

In IDEAl and tabbed pages mode, all forms are maximized, there is no "restore" mode. However, this mode would be more appropriate, in particular when previewing. A possible solution would be to create first a workspace (or someting similar) and then to create forms in "restore" mode.

3.2. Form Resize Modes for form windows inside Kexi

 2004-12-14, jstaniek

A form is built in three layers: KexiDBForm widget is an only child of KexiFormScrollView (QScrollView) which is a main widget inserted into KexiFormView (KexiViewBase subclass). Thanks to reimplementing QScrollView, we've got ability of displaying scroll bars on demand.

Following resize modes are implemented for data view mode:

• Auto (the default). Resize policy of KexiFormScrollView is set to AutoOneFit (see QScrollView::setResizePolicy()). This means that:
  • if a form window is smaller than form's size predefined on design time (by dragging its boundaries), scrollbars are presented (or one of them)
  • else: scrollbars are hidden and form's surface is resized, so no gray scrollview's surface is visible at all.
  • When maximized, form's window resizes it's contents.
  • On opening, if it's in restored mode (unmaximized), (it's possible for childframe or toplevel mode) form's window size hint equals to default form's size predefined on design time, as described above.
  • Form's boundaries (left and bottom) are invisible, since form's surface takes entire window's contents.
  • Note Auto doesn't mean that form's widget are layed out. They can be layed out to better fit contents only if user defined form's layout.

• Fixed. Resize policy of KexiFormScrollView is set to Manual. Form's contents are not resized upon form window resize/maximizing/restoring.
  • Form's (left and bottom) boundaries are visible, the form's surface is top-left aligned. This is regardless of form's layout settings. Grayed surface is visible beyond boundaries.

3.3. Related form's properties

• "Horizontal scrollbar" : "As needed"(def) | "Always" | "Never"
• "Vertical scrollbar" : "As needed"(def) | "Always" | "Never"

3.4. Notes

• These are Kexi-specific modes, available using property editor (not available from KFormDesigner). This can be changed in the future for user's convenience.
• In Design view mode the QScrollView container has always Manual resize policy, what enables user to drag form's boundaries.

3.5. "Edit indicator" for standard forms

Standard form (not continuous) can usually take entire screen size. In MSA there's displayed a record indicator with an arrow pointing to the current record, see [1] on the picture.

Since it's good for continuous forms, it's a nonsense for standard forms since there's always displayed one record at the time.

The proposal is to move edit indicator down to the record navigator, on the left hand, see [2] on the picture. It's "pen" icon will be displayed only on edit time. Except edit time, there will be empty area displayed in this place.

Status: IMPLEMENTED in Kexi 0.8